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Abstract 


This document defines four new Job Description attributes for 
monitoring job progress to be registered as OPTIONAL extensions to 
the Internet Printing Protocol (IPP/1.0 and IPP/1.1). These 
attributes are drawn from the PWG Job Monitoring MIB. This document 
also defines a new "sheet-collate" Job Template attribute to control 
sheet collation and to help with the interpretation of the job 
progress attributes. 
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1 Introduction 


This document defines four new Job Description attributes for 
monitoring job progress to be registered as OPTIONAL extensions to 
IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911]. These attributes are drawn 
from the PWG Job Monitoring MIB [RFC2707]. See section 10 fora 
description of the base IPP documents. The new Job Description 
attributes are: 


"job-collation-type" (type2 enum) 
"sheet-completed-copy-number" (integer (0:MAX) ) 
"sheet-completed-document-number" (integer (0:MAX) ) 
"impressions-completed-current-copy" (integer (0:MAX) ) 


This document also defines a new "sheet-collate" Job Template 
attribute to control sheet collation and to help with the 
interpretation of the job progress attributes. These new attributes 
may also be used by themselves in combination with the IPP/1.1 "job- 
impressions-completed" attribute, as useful job progress monitoring 
attributes and/or may be passed in an IPP Notification (see [ipp- 
ntfy]). 
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This section defines terminology used throughout this document. 


2.1 Conformance Terminology 


Capitalized terms, 

NOT, MAY, NEED NOT, 
conformance, 
LD A 
document, 


2.2 Other terminology 


This document uses terms such as Job object 
"operation", 
These terms have special meaning and are defined 


object (or Printer), 


and "impression". 
in the model terminology 


3 Job Template attributes 


3.1 sheet-collate 


such as MUST, MUST NOT, 
and OPTIONAL, have special meaning relating to 
as defined in RFC 2119 
If an implementation supports the extension defined in this 
then these terms apply; 
terms define conformance to this document only; 
conformance to other documents, 


REQUIRED, SHOULD, SHOULD 


[RFC2119] and [RFC2911] section 
they do not. These 
they do not affect 


unless explicitly stated otherwise. 


otherwise, 


IPP Printer 
"support", 


(or Job), 
"attribute", "keyword", 


[RFC2911], section 12.2. 


(type2 keyword) 


t t t t 
| Job Attribute |Printer: Default Value| Printer: Supported | 
| | Attribute | Values Attribute | 
+ + + + 
| sheet-collate | sheet-collate-default | sheet-collate- | 
| (type2 keyword) | (type2 keyword) | supported (1setOf | 
| | | type2 keyword) | 
4------------------- q4---------------------- 4--------------------- t 


This attribute specifies whether or not the media sheets of each copy 


of each printed document in a job are to be in sequence, 


when 


multiple copies of the document are specified by the 'copies' 


attribute. 


Standard keyword values are: 


'uncollated': 
times in succession 
attribute, followed 


'collated': each copy 
print-stream sheets 


copy. 


Hastings, et. al. 


each print-stream sheet is printed a number of 


equal to the value of the 'copies' 
by the next print-stream sheet. 


of each document is printed with the 
in sequence, followed by the next document 
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For example, suppose a document produces two media sheets as output, 
and "copies" is equal to '6'. For the 'uncollated' case, six copies 
of the first media sheet are printed, followed by six copies of the 
second media sheet. For the 'collated' case, one copy of each of the 
Six sheets is printed, followed by another copy of each of the six 
media sheets. 


Whether the effect of sheet collation is achieved by placing copies 
of a document in multiple output bins, or in the same output bin with 
implementation defined document separation, is implementation 
dependent. Also whether it is achieved by making multiple passes 
over the job or by using an output sorter, is implementation 
dependent. 


Note: IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911] are silent on whether 
or not sheets within documents are collated. The "sheet-collate- 
supported" Printer attribute permits a Printer object to indicate 
whether or not it collates sheets with each document and whether it 
allows the client to control sheet collation. An implementation is 
able to indicate that it supports uncollated sheets, collated sheets, 
or both, using the 'uncollated', 'collated', or both 'uncollated' and 
'collated' values, respectively. 


This attribute is affected by "multiple-document-handling". The 
"multiple-document-handling" attribute describes the collation of 
documents, and the "sheet-collate" attribute describes the semantics 
of collating individual pages within a document. To better explain 
the interaction between these two attributes, the term "set" is 
introduced. A "set" is a logical boundary between the delivered 
media sheets of a printed job. For example, in the case of a ten 
page single document with collated pages and a request for 50 copies, 
each of the 50 printed copies of the document constitutes a "set". 

In the above example if the pages were uncollated, then 50 copies of 
each of the individual pages within the document would represent each 
" set " : 
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The following table describes the interaction of "sheet-collate" with 
multiple document handling. 


"sheet- 
collate" 


‘collated’ 


‘collated’ 


‘collated’ 


‘collated’ 


'uncollated"' 


'uncollated"' 


'uncollated"' 


'uncollated"' 


Hastings, 


et. 


al. 


"multiple- 
document- 
handling" 


' single- 
document’ 


' single- 
document-new- 
sheet" 


'separate- 
documents- 
collated- 
copies' 


'separate- 
documents- 
uncollated- 
copies 


'single- 
document" 


'single- 
document-new- 
sheet" 


'separate- 
documents- 
collated- 
copies’ 


'separate- 
documents- 
uncollated- 
copies 


Standards 


Semantics 


Each copy of the concatenated 
documents, with their pages in 
Sequence, represents a "set". 


Each copy of the concatenated 
documents, with their pages in 
Sequence, represents a "set". 


Each copy of each separate 
document, with its pages in 
Sequence, represents a "set". 


Each copy of each separate 
document, with its pages in 
Sequence, represents a "set". 


Each media sheet of the document 
is printed a number of times equal 
to the "copies" attribute; which 
constitutes a "set". 


Each media sheet of the 
concatenated documents is printed 
a number of times equal to the 
"Copies" attribute; which 
constitutes a "set". 


This is a degenerate case, and the 
printer object MUST reject the job 
and return the status, "client- 
error-conflicting-attributes". 


This is a degenerate case, and the 
printer object MUST reject the job 
and return the status "client- 
error-conflicting-attributes". 
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From the above table it is obvious that the implicit value of the 
"sheet-collate" attribute in a printer that does not support the 
"sheet-collate" attribute, is 'collated.' The semantics of 
"multiple-document-handling" are otherwise nonsensical in the case 
of separate documents. 


4 IPP Job Description attributes for monitoring Job Progress 


The following IPP Job Description attributes are proposed to be added 
to IPP through the type2 registration procedures. They are useful 
for monitoring the progress of a job. They are also used as 
attributes in the notification content in a notification report 
[ipp-ntfy]. 


There are a number of Job Description attributes for monitoring the 
progress of a job. These objects and attributes count the number of 
K octets, impressions, sheets, and pages requested or completed. For 
impressions and sheets, "completed" means stacked, unless the 
implementation is unable to detect when each sheet is stacked, in 
which case, stacked is approximated when the processing of each sheet 
is completed. There are objects and attributes for the overall job 
and for the current copy of the document currently being stacked. 

For the latter, the rate at which the various objects and attributes 
count, depends on the sheet and document collation of the job. 


Consider the following four Job Description attributes that are used 
to monitor the progress of a job's impressions: 


1. "job-impressions-completed" - counts the total number of 
impressions stacked for the job (see [RFC2911] section 
4.3.18.2). 

2. "impressions-completed-current-copy" - counts the number of 


impressions stacked for the current document copy. 


3. "sheet-completed-copy-number" - identifies the number of the 
copy for the current document being stacked, where the first 
copy is 1. 

4. "sheet-completed-document-number" - identifies the current 


document within the job that is being stacked, where the first 
document in a job is 1. NOTE: this attribute SHOULD NOT be 
implemented for implementations that only support one document 
per job. 
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For each of the three types of job collation, a job with three copies 
of two documents (1, 2), where each document consists of 3 
impressions, the four variables have the following values, as each 
sheet is stacked for one-sided printing: 


"job-collation-type" = 'uncollated-sheets (3)' 


"job- "impressions- "sheet- "sheet- 

impressions- completed- completed- completed- 

completed" current-copy" copy-number" document- 
number" 


«000 -10014 C) m| Oo 


Q Q Q DID IO I :P QOO Q IND ION. Io P. S O 
WNHEWNHEWNHEWNHEWNHEWNEO 
NNNNNNNNNRPRPRBPERPEHPEHEHO 
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"job-collation-type" = 'collated-documents (4)" 
"job- "impressions- "sheet- "sheet- 
impressions- completed- completed- completed- 
completed" current-copy" copy- document- 
number" number" 
0 0 0 0 
1 1 I: Į 
2 2 1 1 
3 3 1 1 
4 1 1 2 
5 2 1 2 
6 3 1 2 
7 1 2 1 
8 2 2 1 
9 3 2 1 
10 1 2 2 
Ll 2 2 2 
12 3 2 2 
L3 I 3 1 
14 2 3 1 
15 3 3 I 
16 1 3 2 
Tf 2 3 2 
18 3 3 2 
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"job-collation-type" = 'uncollated-documents (5)"' 


"job- "impressions- "sheet- "sheet- 

impressions- completed- completed- completed- 

completed" current-copy" copy-t document- 
number" number" 


«000-1001 4» C0) 9| Oo 


WNHEWNHEWNHEWNHEWNHEWNEO 
Q Q Q Do io IP Q0 Q BIO. 0 0 O 
NNNNNNNNNRPRPRBHEBHEBPHPRHO 


4.1 job-collation-type (type2 enum) 


Job Collation includes sheet collation and document collation. Sheet 
collation is defined to be the ordering of sheets within a document 
copy. Document collation is defined to be the ordering of document 
copies within a multi-document job. The value of the "job- 
collation-type" is affected by the value of the "sheet-collate" Job 
Template attribute (see section 3.1), if supplied and supported. 


The Standard enum values are: 


‘1’ ‘other’: not one of the defined values 
'2' 'unknown': the collation type is unknown 
'3' '"uncollated-sheets': No collation of the sheets within each 


document copy, i.e., each sheet of a document that 
is to produce multiple copies, is replicated before 
the next sheet in the document is processed and 
stacked. If the device has an output bin collator, 
the 'uncollated-sheets(3)' value may actually 
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produce collated sheets as far as the user is 
concerned (in the output bins). However, when the 
job collation is the 'uncollated-sheets(3)' value, 
job progress is indistinguishable from a monitoring 
application between a device that has an output bin 
collator and one that does not. 


'4' 'collated-documents':  Collation of the sheets within each 
document copy is performed within the printing 
device by making multiple passes over, either the 
Source or an intermediate representation of the 
document. In addition, when there are multiple 
documents per job, the i'th copy of each document is 
Stacked before the j'th copy of each document, i.e., 
the documents are collated within each job copy. 

For example, if a job is submitted with documents, A 
and B, the job is made available to the end user as: 
A, B, A, B, .... The 'collated-documents(4)' value 
corresponds to the IPP [RFC2911] 'separate- 
documents-collated-copies' keyword value of the 
"multiple-document-handling" attribute. 


If the job's "copies" attribute is '1' (or not 
supplied), then the "job-collation-type" attribute 
is defined to be '4'. 


'5' 'uncollated-documents': Collation of the sheets within each 
document copy is performed within the printing 
device by making multiple passes over either the 
Source or an intermediate representation of the 
document. In addition, when there are multiple 
documents per job, all copies of the first document 
in the job are stacked before any copied of the next 
document in the job, i.e., the documents are 
uncollated within the job. For example, if a job is 
submitted with documents, A and B, the job is made 
available to the end user as: A, A, ..., B, B, 

The 'uncollated-documents(5)' value corresponds to 
the IPP [RFC2911] 'separate-documents-uncollated- 
copies' keyword value of the "multiple-document- 
handling" attribute. 
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4.2 sheet-completed-copy-number (integer (0:MAX) ) 


The number of the copy being stacked for the current document. This 
number starts at 0, is set to 1 when the first sheet of the first 
copy for each document is being stacked and is equal to n where n is 
the nth sheet stacked in the current document copy. If the value is 
unknown, the Printer MUST return the ’unknown’ out-of-band value (see 
[RFC2911] section 4.1), rather than the -2 value used in some MIBs 
[RFC2707]. 


4.3 sheet-completed-document-number (integer (0:MAX) ) 


The ordinal number of the document in the job that is currently being 
stacked. This number starts at 0, increments to 1 when the first 
sheet of the first document in the job is being stacked, and is equal 
to n where n is the nth document in the job, starting with 1. If the 
value is unknown, the Printer MUST return the ’unknown’ out-of-band 
value (see [RFC2911] section 4.1), rather than the -2 value used in 
some MIBs [RFC2707]. 


Implementations that only support one document job SHOULD NOT 
implement this attribute. 


4.4 impressions-completed-current-copy (integer (0:MAX) ) 


The number of impressions completed by the device for the current 
copy of the current document so far. For printing, the impressions 
completed includes interpreting, marking, and stacking the output. 
For other types of job services, the number of impressions completed 
includes the number of impressions processed. If the value is 
unknown, the Printer MUST return the ’unknown’ out-of-band value (see 
[RFC2911] section 4.1), rather than the -2 value used in some MIBs 
[RFC2707]. 


This value MUST be reset to 0 for each document in the job and for 
each document copy. 


5 Conformance Requirements 


This section summarizes the Conformance Requirements detailed in the 
definitions in this document. In general each of the attributes 
defined in this document are OPTIONAL for a client and/or a Printer 
to support, so that client and Printer implementers MAY implement any 
combination of these attributes. 
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6 IANA Considerations 


This section contains registration information for IANA to add to the 
IPP Registry according to the procedures defined in RFC 2911 
[RFC2911], section 6. The resulting registrations will be published 
in the http://www.iana.org/assignments/ipp-registrations registry. 


6.1 Attributes 


Job Template attributes: Ref. Section: 
sheet-collate (type2 keyword) RFC 3381 Zal 
sheet-default (type2 keyword) RFC 3381 Sul 
sheet-supported (lsetOf type2 keyword) RFC 3381 3.1 
Job Description attributes: Ref. Section: 
job-collation-type (type2 enum) RFC 3381 4-1. 
sheet-completed-copy-number (integer (0:MAX) ) RFC 3381 4.2 
sheet-completed-document-number (integer (0:MAX))RFC 3381 4.3 
impressions-completed-current-copy (integer (0:MAX) ) 

RFC 3381 4.4 


6.2 Keyword Attribute Values 


The following table provides registration information for all of the 
attributes defined in this document that have keyword values. These 
keywords are to be registered according to the procedures defined in 
RFC 2911 [RFC2911] section 6.1. 


sheet-collate (type2 keyword) RFC 3381 Zel 
'uncollated' RFC 3381 3. 
' collated' RFC 3381 ST 

sheet-collate-default (type2 keyword) RFC 3381 3l 
See "sheet-collate" attribute 

sheet-collate-supported (1setOf type2 keyword)  RFC 3381 SAT 


See "sheet-collate" attribute 
6.3 Enum Attribute Values 


The following table provides registration information for all of the 
attributes defined in this document that have enum values. These 
enums are to be registered according to the procedures defined in RFC 
2911 [RFC2911] section 6.1. 


job-collation-type (type2 enum) RFC 3381 4.1 
"i4 'other' RFC 3381 4.1 
Poe ‘unknown’ RFC 3381 4.1 
134 'uncollated-sheets' RFC 3381 4.1 
"ar ' collated-documents"' RFC 3381 4.1 
£5 'uncollated-documents"' RFC 3381 4.1 
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7 Internationalization Considerations 


The IPP extensions defined in this document require the same 
internationalization considerations as any of the Job Template and 
Job Description attributes defined in IPP/1.1 [RFC2911]. 


8 Security Considerations 


The IPP extensions defined in this document require the same security 
considerations as any of the Job Template attributes and Job 
Description attributes defined in IPP/1.1 [RFC2911]. 
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10 Description of the Base IPP Documents 
The base set of IPP documents includes: 


Design Goals for an Internet Printing Protocol [RFC2567] 
Rationale for the Structure and Model and Protocol for the 
Internet Printing Protocol [RFC2568] 

Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 
Internet Printing Protocol/1.1: Implementer's Guide [RFC3196] 
Mapping between LPD and IPP Protocols [RFC2569] 


The "Design Goals for an Internet Printing Protocol" document takes a 
broad look at distributed printing functionality, and enumerates 
real-life scenarios that help to clarify the features that need to be 
included in a printing protocol for the Internet. It identifies 
requirements for three types of users: end users, operators, and 
administrators. It calls out a subset of end user requirements that 
are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator 
operations have been added to IPP/1.1 [RFC2911, RFC2910]. 


The "Rationale for the Structure and Model and Protocol for the 
Internet Printing Protocol" document describes IPP from a high level 
view, defines a roadmap for the various documents that form the suite 
of IPP specification documents, and gives background and rationale 
for the IETF IPP working group's major decisions. 


The "Internet Printing Protocol/1.1: Model and Semantics" document 
describes a simplified model with abstract objects, their attributes, 
and their operations. The model introduces a Printer and a Job. The 
Job supports multiple documents per Job. The model document also 
addresses how security, internationalization, and directory issues 
are addressed. 


The "Internet Printing Protocol/1.1: Encoding and Transport" document 
is a formal mapping of the abstract operations and attributes defined 
in the model document onto HTTP/1.1 [RFC2616]. It also defines the 
encoding rules for a new Internet MIME media type called 
"application/ipp". This document also defines the rules for 
transporting over HTTP a message body whose Content-Type is 
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"application/ipp". This document defines the 'ipp' scheme for 
identifying IPP printers and jobs. 


The "Internet Printing Protocol/1.1: Implementer's Guide" document 
gives insight and advice to implementers of IPP clients and IPP 
objects. It is intended to help them understand IPP/1.1 and some of 
the considerations that may assist them in the design of their client 
and/or IPP object implementations. For example, a typical order of 
processing requests is given, including error checking. Motivation 
for some of the specification decisions is also included. 


The "Mapping between LPD and IPP Protocols" document gives some 
advice to implementers of gateways between IPP and LPD (Line Printer 
Daemon) implementations. 


In addition to the base IPP documents, the "Event Notification 
Specification" document [ipp-ntfy] defines OPTIONAL operations that 
allow a client to subscribe to printing related events. 
Subscriptions include "Per-Job subscriptions" and "Per-Printer 
subscriptions". Subscriptions are modeled as Subscription objects. 
Four other operations are defined for subscription objects: get 
attributes, get subscriptions, renew a subscription, and cancel a 
subscription. 
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12 Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
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